Daniel van Vugt [Fri, 12 Mar 2021 06:13:18 +0000 (14:13 +0800)]
status/network: Ensure the Cancel button passes undefined to close()
The parameter to `ModalDialog.close(timestamp)` is optional. But when
invoked via the network dialog's Cancel button it was receiving an
implicit parameter value that's definitely not a timestamp:
And as of today (or gjs >= 1.67.3) that's reported as an error:
```
JS ERROR: Error: Argument timestamp: value is out of range for uint32
popModal@resource:///org/gnome/shell/ui/main.js:638:12
popModal@resource:///org/gnome/shell/ui/modalDialog.js:206:14
close@resource:///org/gnome/shell/ui/modalDialog.js:179:14
```
and so you can't Cancel the dialog anymore.
Make sure `ModalDialog.close()` receives an `undefined` timestamp it
knows how to handle.
Since commit 770231, StImageContent implements the GIcon interface, which
allowed us to represent all application icons as GIcon (app-info, X11 icon
property or themed fallback icon).
While that change made for a nicer ShellApp API, it did introduce a
conceptual issue in st_texture_cache_bind_cairo_surface_property():
GIcons usually represent static icons, while the ClutterContent
returned by that method updates automatically when the bound property
changes.
Address this by tracking the MetaWindow:icon property in ShellApp, and
update the fallback icon when it changes. With that, a GIcon object
always represents the same icon, and any icon change is reflected
by a corresponding GIcon change.
Florian Müllner [Fri, 12 Mar 2021 22:13:25 +0000 (23:13 +0100)]
shell/app: Expose icon as property
A property can be more convenient than a method. More importantly,
we are about to allow the icon to change, so a property will be
useful to get notified about those changes.
Florian Müllner [Sat, 13 Mar 2021 23:10:56 +0000 (00:10 +0100)]
shell/app: Only release window ref when we are done
We hold a reference to all windows we track for the app. While that
reference is unlikely to be the last remaining one, we still shouldn't
release it until we are done with the window.
Creating a content object from a cairo surface may fail, in which case
we return an empty content with a 0x0 preferred size.
However when we treat such a content object as GIcon, we happily load
it anyway. Don't do that, so consumers like StIcon can fall back properly
to an alternative.
Sebastian Keller [Sun, 14 Mar 2021 16:32:26 +0000 (17:32 +0100)]
iconGrid: Only use page relative coords for orientation in getDropTarget
The x and y coordinates were both adjusted to be page relative, even
though the icon grid can only scroll in one direction. This was leading
to coordinates outside of the icon grid to be considered part of it and
a wrong drop target to be chosen.
Sebastian Keller [Wed, 10 Mar 2021 16:27:42 +0000 (17:27 +0100)]
st/texture-cache: Ensure icons keep their aspect ratio when scaled down
Window preview icons can get scaled down if the window they belong to is
very small and/or there are a lot of open windows. When scaled down this
way the icons would get scaled without keeping the aspect ratio. Fix
this by using a content gravity that keeps the aspect ratio.
Sebastian Keller [Wed, 10 Mar 2021 15:39:53 +0000 (16:39 +0100)]
st/texture-cache: Don't use content size request mode for surface icons
While most GIcons passed to this function cause a StImageContent to be
created with the requested size, cairo surface based icons already are
passed as StImageContent with a preferred size corresponding to the
size of the surface they were created from. As a result icons of window
backed applications were never scaled up like the other icons. Fix this
by ignoring the content size for these case.
Jonas Dreßler [Tue, 9 Mar 2021 16:31:30 +0000 (17:31 +0100)]
overview: Get rid of panel ghost actor
Right now we use a ClutterClone ghost of the panel simply to add some
spacing to the top monitor edge.
We can remove the panelGhost by adjusting the allocations of all the
parts of the overview ourselves inside ControlsManagers vfunc_allocate,
this should also work with extensions that move the panel somewhere
else.
This makes the initial relayout of the overview significantly faster,
because we now no longer have to relayout the whole panel in the
process.
Jonas Dreßler [Thu, 11 Mar 2021 14:26:14 +0000 (15:26 +0100)]
overviewControls: Return zero preferred size
The OverviewControls actor gets allocated a fixed size by its parent,
the OverviewActor, anyway, so it's pretty useless to go through the size
request machinery and add up all the sizes of items in the iconGrid,
coming up with a preferred size that's wrong anyway.
Instead simply return a min and preferred size of 0 in
get_preferred_height/width of ControlsManagerLayout.
Jonas Dreßler [Tue, 9 Mar 2021 16:37:22 +0000 (17:37 +0100)]
overviewControls: Hide the appDisplay when it's not shown
Hiding actors allows excluding them from layout, so by hidding the
appDisplay in all the cases where the overviewAdjustment is not actually
showing it, we can save a lot of time on the first frame of painting
the overview because we no longer have to layout the whole appGrid.
Jonas Dreßler [Tue, 2 Mar 2021 10:47:13 +0000 (11:47 +0100)]
iconGrid: Subclass a C actor for BaseIcon
We create a lot of BaseIcons for the appGrid, one for every app, and for
all of those we have to hop through JS to get the preferred width. That
makes it another obvious target for moving to C, so let's do that.
Jonas Dreßler [Sat, 20 Feb 2021 12:58:39 +0000 (13:58 +0100)]
keyboard: Correctly compare cursor rect to keyboard rect
The logic that decides whether we should shift the window up when the
cursor rectangle overlaps with the keyboard rectangle doesn't work
properly right now, we want it to work like this:
- If the currently focused window is shifted up, keep it shifted up
until the cursor rect no longer overlaps the keyboard rect. To do that
comparison correctly, we need to adjust for the height the cursor rect
is shifted up by (keyboardHeight) and temporarily shift it down again.
- If the currently focused is not shifted up, we want to shift it up as
soon as the focus rect overlaps the keyboard rect. If that's not the
case, want still want to call _setFocusWindow(null) in order to shift
the previously focused window back down.
This fixes two issues: 1) We're currently shifting windows back down at
the wrong position of the cursor (that is y < keyboardHeight). 2) We're
not shifting down previously focused windows when focusing a different
window with the new focus in a specific region (y >= keyboardHeight &&
y + h < monitor.y + monitor.height - keyboardHeight).
Jonas Dreßler [Fri, 26 Feb 2021 15:08:20 +0000 (16:08 +0100)]
keyboard: Add proper tracking of window movements to focus tracker
So far the FocusTracker of the OSK can only recognize grab ops on a
window, that is when the user grabs the window using a mouse or the
touchscreen and actively drags it somewhere.
Window can also be moved using keyboard shortcuts, fullscreen buttons or
other ways which don't rely on grabs. Start also supporting those window
movements by listening to the "position-changed" signal on the currently
focused window and emitting the new "window-moved" signal in that case.
Because the OSK sometimes moves windows by itself, we temporarily
disconnect from that new signal while we move the focused window in
_windowSlideAnimationComplete().
This also takes care of resetting this._focusWindowStartY on movements
of the window.
Jonas Dreßler [Sat, 20 Feb 2021 11:55:58 +0000 (12:55 +0100)]
keyboard: Animate focus window using position instead of translation-y
Commit 8526776b4a53d9a801197fb66ce9a282323c1c4e changed the OSK to use
the translation-y property of the MetaWindowActor when animating a focus
window, which broke two things:
1) It's not compatible with the obscured region culling we do for
windows in mutter. That's because MetaCullable strictly operates in
integer coordinates and thus has to ignore any transformations
(translation-y is a transformation). Because of this, during the
animation and gesture, window damage is now tracked incorrectly,
introducing painting issues. The best fix for this would probably be
factoring in transformations when tracking damage in MetaCullable, but
that's not feasible right now.
2) It broke the shifting up of maximized and tiled windows, likely that
is because they are positioned using constraints internally, and mutter
enforces those constraints every time meta_window_move_frame() is
called, not allowing the window to move somewhere else.
To fix both issues, go back to the old way of shifting the window for
now, using the fixed y position of the ClutterActor. To make sure the
drag-up gesture still works, store the initial y1 position of the window
and then use that as a reference point for all our animations.
Jonas Dreßler [Sat, 20 Feb 2021 12:57:51 +0000 (13:57 +0100)]
keyboard: Don't move focusWindow back down on window grab
I suggested it myself when reviewing
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668, so
here I am reverting that again...
The difference between calling _setFocusWindow(null) and simply
unsetting the focusWindow is that the former animates the window back to
its position before we shifted it up, while the latter simply "lets go
of the window".
In this case we actually want the latter because after the user grabbed
the window, we obviously should not animate it away right underneath the
users pointer/finger.
To ensure the same mistake doesn't happen again, add a small comment
explaining why this code is as it is.
swipeTracker: Reset before emitting 'end' and not after
If the actor is unmapped in the handler, the touch gesture will cancel.
Since we haven't reset the state yet, it will still work and will actually
cancel the gesture, so reset before that instead.
Fixes overview cancelling when trying to open it with a swipe.
When this class was written, all swipes in the shell were vertical, so it
made sense to make the default orientation vertical. This isn't the case
anymore, thus pass make it mandatory to specify orientation when creating
a tracker.
Change the property default values to horizontal as well to match Clutter
instead of the old shell design.
Jonas Dreßler [Sat, 27 Feb 2021 10:37:24 +0000 (11:37 +0100)]
keyboard: Stop offsetting the focus rectangle
The focus rectangle of the OSK currently gets stored with an offset that
removes the global coordinates and makes it window-local coordinates.
This offsetting has been applied since the introduction of the
FocusTracker with commit fc5ab4470445992b1ad4338290deb24e6b1c5ce2 and it
seems there's no real reason for it.
By removing this, we also emit position-changed when the window has
moved but the window-local coordinates stayed the same. We really want
to emit position-changed in that case because it might affect whether
the window needs to be shifted up.
Jonas Dreßler [Sat, 27 Feb 2021 10:27:23 +0000 (11:27 +0100)]
keyboard: Ignore focus rects outside the window
Apparently some clients, including gtk don't "clip" the focus rectangle
to their window bounds when scrolling the focus outside the window. This
makes us shift up windows when the focus actually is no longer visible.
This issue needs fixing in GTK, it should probably stop reporting
focus changes when the focus moves outside of the visible view. We can
still do a little bit better on our side though and "clip" the rectangle
to the windows frame rect: If it moves out of the window, we simply stop
updating our focus rect.
The intersection check introduces a small problem though: Some clients
(for example gedit) will give us a cursor rect that has a 0 width or
height. This won't play well with graphene_rect_intersect()
(GrapheneRects never intersect if they are 0-sized), so we set the size
to 1 in case we get a 0-sized rectangle.
Jonas Dreßler [Fri, 26 Feb 2021 14:52:06 +0000 (15:52 +0100)]
keyboard: Initialize the FocusTrackers current window correctly
The FocusTracker keeps track of the currently focused window using its
internal this._currentWindow property. It will only pick up the focused
window though when receiving a "notify::focus-window" signal, so the
focused window that's set when the FocusTracker is created won't be
picked up.
Fix that by setting the _currentWindow during creation of the
FocusTracker.
Jonas Dreßler [Sat, 20 Feb 2021 11:51:32 +0000 (12:51 +0100)]
keyboard: Make a few functions private
Now that we got rid of the external calls to setCursorLocation(), we can
make that private. animateShow() and animateHide() weren't called from
outside anyway, so let's make those private, too.
Jonas Dreßler [Thu, 18 Feb 2021 11:23:59 +0000 (12:23 +0100)]
keyboard: Rename focusTracker "reset" signal to "window-grabbed"
What this signal does is fire when a window was grabbed. A receiver
might want to do something special when a window was grabbed, whereas
"reset" can mean anything. Rename the "reset" signal to
"window-grabbed".
Florian Müllner [Tue, 9 Mar 2021 19:48:47 +0000 (20:48 +0100)]
messageTray: Remove deprecated code
Originally the Source method for showing notifications was "notify",
which had to change when turning it into a GObject subclass to not
clash with g_object_notify().
That change happened during the 3.36 cycle, so extensions have had
two releases (a year) to adapt to the replacement. That seems long
enough, so remove the deprecated compat code.
Jakub Steiner [Tue, 9 Mar 2021 19:22:37 +0000 (20:22 +0100)]
styling: Update for darker system grey
- darken buttons similarly to the app grid groups
- entries as well
- adjust foreground color of additional elements to
work for 'light' variant as well
Jonas Dreßler [Thu, 25 Feb 2021 16:20:42 +0000 (17:20 +0100)]
workspace: Use Util.lerp() instead of actor box for interpolating
Instead of interpolating our workspace and layout boxes for each child
using clutter_actor_box_interpolate(), use our Util.lerp() function and
stay in JS land instead.
This is quite a large performance improvement since it avoids
heap-allocating a new ClutterActorBox for every child. With this, we're
finally at a duration of 1.0 ms to allocate the Workspace with 20
windows.
Jonas Dreßler [Thu, 25 Feb 2021 11:13:21 +0000 (12:13 +0100)]
workspace: Get some values outside the children loop when allocating
It turned out that getting properties and saving them to a variable
outside of loops instead of accessing them everytime inside the loop can
have significant impact on performance, so do that in Workspaces
vfunc_allocate().
Here the impact is not that large, about 0.05 ms with 20 open windows,
that still seems worth it though.
Jonas Dreßler [Thu, 25 Feb 2021 10:57:22 +0000 (11:57 +0100)]
workspace: Don't do checks in animateAllocation()
These checks aren't needed since Clutter should enforce this for us
already and skip the implicit transition when possible. This gets our
time spent in vfunc_allocate() down to 2.0 ms with 20 windows
Jonas Dreßler [Thu, 25 Feb 2021 10:50:44 +0000 (11:50 +0100)]
workspace: Iterate windowSlots directly when allocating
We can save a little bit of time in this loop by iterating directly
over the windowSlots array instead of iterating through children and
then performing a search for the windowSlot. This saves more time and we
only spend 2.2 ms instead of 2.3 ms in vfunc_allocate() now.
Jonas Dreßler [Sat, 20 Jun 2020 15:22:30 +0000 (17:22 +0200)]
Move WindowPreviewLayout from JS to C
This layout manager is used quite often and the time we spend calling
it's allocate and get_preferred_width/heigth functions increases with
every open window.
We can save a lot of precious time during the layout cycle by moving
this layout manager from JS to C, thus avoiding the overhead of
trampolining between C and JS land.
In a measurement where the average time spent in vfunc_allocate() of the
Workspace actor was measured while opening an overview with 20 windows,
the average time spent went down from 3.1 ms to 2.3 ms.
Jonas Dreßler [Mon, 1 Mar 2021 09:21:58 +0000 (10:21 +0100)]
panel: Don't change text color when entering the overview or lockscreen
With the introduction of the transparent panel in the overview, we
started making the panel text/icon color slightly brighter in the
overview and on the lockscreen to ensure best contrast. Now
unfortunately, setting the text color incurred a relayout of the
underlying ClutterText actor (fixed with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1750), and
setting the icon color causes the icon texture to get regenerated
(fixed with
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932).
Regenerating the icon texture will replace the icon actor, which also
causes a relayout.
This relayout of the panel has been measured to add at least 1
millisecond (the numbers fluctuated a lot) to about 5 ms it takes to
layout the first frame when showing the overview.
Since https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932 is
unlikely to land this cycle, this commit proposes a different solution:
Simply don't use a different color for text in the overview. To avoid
issues with contrast in the overview, make the default color slightly
brighter and change it from #ccc to #ddd.
Jonas Dreßler [Mon, 1 Mar 2021 09:07:27 +0000 (10:07 +0100)]
panel: Only update appMenu icon when the app actually changed
Right now we always recreate the icon of the appMenu when calling
_sync(). This will relayout the panel everytime we open the overview,
because we call _sync() in that case.
We can easily avoid that by only recreating the icon actor in case the
app that's opened actually changes. This gets us close to doing no more
relayouts of the panel when opening the overview.
Jonas Dreßler [Mon, 1 Mar 2021 09:03:50 +0000 (10:03 +0100)]
panel: Don't completely hide AppMenuButton when invisible
We already set the AppMenuButton to be non-reactive and transparent when
we hide it. Hiding it completely using clutter_actor_hide() will
additionally make it no longer affect layout and thus queue a relayout.
Since we hide the appMenu in the overview and we want to avoid
relayouting the panel when entering and leaving the overview, don't
completely hide the AppMenuButton to avoid queueing this relayout.
Florian Müllner [Mon, 8 Mar 2021 18:59:23 +0000 (19:59 +0100)]
windowManager: Limit super-scroll handling to normal mode
The overview has it's own workspace scroll handling, and we don't want
to switch workspaces in other modes. Limiting the scroll-event handler
to NORMAL mode matches the swipe tracker used by WorkspaceAnimation,
and allows for other uses of scroll events (like scrolling in the
alt-tab popup).
Sebastian Keller [Thu, 25 Feb 2021 23:00:06 +0000 (00:00 +0100)]
ctrlAltTab: Fix usage of bind_cairo_surface_property
This updates the use of bind_cairo_surface_property for the changes
from d7cb2eeebc. Now this function returns a StImageContent and not
an Actor like the following code expects, so wrap it in a StIcon.
Also the function lost its size argument.
Sebastian Keller [Thu, 25 Feb 2021 22:56:11 +0000 (23:56 +0100)]
st/texture-cache: Change bind_cairo_surface_property to transfer full
This is how the code works and how it is already used from the C side.
There would also be no point in keeping this transfer none, because
textures generated from this function will not be shared and are not
kept in the cache.
The commit did not fix the bug it was supposed to fix, it just
complicated the code. The hopefully correct fix is in the previous
commit.
The point of this commit was to ensure everything gets removed when
bind->source gets removed. This however was already the case since the
signal handler was already connected to bind->source and has a
destructor registered that takes care of everything. And since gobject
destroys its signal handlers before it clears the weak refs, this new
weak ref was effectively never being used.
Sebastian Keller [Thu, 25 Feb 2021 16:42:43 +0000 (17:42 +0100)]
st/texture-cache: Don't overwrite existing bind images on texture reset
If the icon surface of a window got updated and its type or format no
longer match what we expect, st_texture_cache_reset_texture() might
overwrite the existing image in the bind with a new image, while still
keeping the weak ref on the old image. Due to this the old image might
trigger a st_texture_cache_on_pixbuf_notify() after the bind has already
been freed by g_signal_handlers_destroy() in the bind source. While this
usually would remove the weak ref, the weak ref it tries to remove is
on the new image, not the old one. The call to
st_texture_cache_on_pixbuf_notify() then tries to read the already
free'd memory from the bind which causes the cast to G_OBJECT to fail,
resulting in the crash.
shell/app: Avoid adding windows with a startup workspace twice
Changing the workspace of a window causes the window tracker to remove
and add it to the app again. If this happens from within
_shell_app_add_window() before the window has been added to the windows
list, this will cause the check that is supposed to prevent adding the
same window multiple times to fail and the window to be added twice.
The app will then be considered still running after the last window has
been closed. Then when clicking on the corresponding app icon, the shell
would attempt to switch to a NULL workspace for the closed window
instead of starting a new instance, resulting in a crash.
Changing the workspace also needs to happen after increasing the
interesting window count, because otherwise removal of the window by
the window tracker would trigger a uint underflow leading the app to be
considered running with UINT_MAX interesting windows, despite having no
windows, leading to crashes right after launching the app.
Jonas Dreßler [Thu, 4 Mar 2021 07:14:03 +0000 (08:14 +0100)]
workspaceThumbnail: Update visibility when showing the overview
There's currently a bug that we continue showing the workspace minimap
when the number of workspaces changes back to 1 during the session (ie.
outside the overview). Fix that by also updating the workspaceThumbnails
visibility when entering the overview.
Jonas Dreßler [Thu, 4 Mar 2021 07:40:23 +0000 (08:40 +0100)]
theme/screen-shield: Use the same background color as in the overview
The overview uses $system_bg_color as its background color, and since we
nowadays show the overview right after starting up, it makes sense to
use the same background color for the login screen.
workspace: Check if index is valid before using it
If the window wasn't in _windowSlots, the index is -1, so the last
element of the array is removed, leading to
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547
I logged the stack trace from removeWindow() and it seems that when you
move the window from the second monitor to another workspace like shown
in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547,
removeWindow() is called twice for it, presumably once for the second
monitor workspace, and then once for the first monitor workspace for
some reason. It is during that call that _windowSlots doesn't contain
the window, so instead the last element (index -1) is removed, leading
to the animation bug.
Florian Müllner [Tue, 2 Mar 2021 18:48:55 +0000 (19:48 +0100)]
workspaceThumbnails: Update indicator on workspace changes
We block state updates while the indicator for the active workspace
is animating. To track that, we check whether the scroll-adjustment's
value matches the active workspace index. That works as long as the
adjustment's value changes after the active workspace, but not when
switching workspaces via SwipeTracker which only changes the active
workspace after transitioning to the new scroll value.
To fix that, update the indicator on workspace changes as well.
Florian Müllner [Wed, 24 Feb 2021 22:26:56 +0000 (23:26 +0100)]
workspaceThumbnail: Queue state update after expanding
New workspaces are added in two steps, first the minimap expands to make
room for the new thumbnail, then the thumbnail animates in. However we
currently don't queue a state update after the first step, so the second
one only happens after one is queued by some other event (like a workspace
switch).
Jonas Dreßler [Wed, 24 Feb 2021 10:29:46 +0000 (11:29 +0100)]
iconGrid: Only animate items when we actually need it
Animating items of the iconGrid involves calling a few more C functions,
which is quite slow. Especially calling ClutterActor.set_easing_delay()
is slow because we override that function in JS to adjust for the
animation slow-down factor. So add a small class variable to make sure
we only animate the icons of the grid when we actually need it.
This makes the average time spent in vfunc_allocate() of the iconGrid go
down to about 0.7 ms.
Jonas Dreßler [Wed, 24 Feb 2021 11:07:03 +0000 (12:07 +0100)]
iconGrid: Save class variables to local ones
It's quite slow to access class variables in JS, especially when they're
backed by GObject properties. To avoid accessing them in every iteration
when we're looping through the children of iconGrid, store those values
to another variable and reuse that inside the loop.
This shaves off another 0.2 ms from iconGrids vfunc_allocate(), getting
the average time spent in that function down from 1.3 ms to 1.1 ms.
Jonas Dreßler [Thu, 25 Feb 2021 17:07:59 +0000 (18:07 +0100)]
iconGrid: Get max child size using existing array of visible children
Using a preexisting array to iterate over is much faster than iterating
over the actors children using a "for ... of" loop, that's because the
latter calls into C functions to get the next actor all the time.
Also, stop using array deconstruction here, it turned out that this is
extremely expensive. When profiling this part of the code, it turned out
that only 9% of the time spent in _getChildrenMaxSize() is spent calling
the get_preferred_height/width() methods. When not using array
deconstruction, this time increased to 22%, still not great, but a lot
better.
Jonas Dreßler [Tue, 23 Feb 2021 18:52:46 +0000 (19:52 +0100)]
iconGrid: Cache visible children of pages
We need to access the visible children of a page in inside
vfunc_allocate(), and since getting those children is quite slow (it
involves iterating over all the children of the actor) let's avoid that
and cache the array instead.
This reduces average time spent in vfunc_allocate() of the iconGrid from
1.6 ms down to 1.4 ms.
Jonas Dreßler [Tue, 23 Feb 2021 18:47:45 +0000 (19:47 +0100)]
iconGrid: Cache max size of children
We call this._getChildrenMaxSize() from the allocate() vfunc of
IconGridLayout. Since the function is quite expensive, it slows the
layout process down a lot, so instead of re-calculating it on every
relayout, cache the max size of children.
This makes the average time spent in vfunc_allocate() of the iconGrid go
down from 2.3 ms to 1.6 ms.
Jonas Dreßler [Wed, 3 Feb 2021 09:37:56 +0000 (10:37 +0100)]
workspace: Center-align window previews if there's only a single row
Instead of always aligning window previews vertically at the bottom of
their row, only do that if we have multiple rows. If there's only a
single row of windows, align every window vertically centered.
This is a very small step towards the new layout for window previews in
the overview, but since the release of 40 is getting nearer and nearer,
changing more is not feasible anymore.
Jonas Dreßler [Fri, 19 Feb 2021 18:37:58 +0000 (19:37 +0100)]
workspace: Decrease spacing between workspaces in the window picker
Use a bit less spacing between the workspaces in the window picker, this
uses more of the available space and makes it easy to take a peek at
adjacent workspaces.
Jonas Dreßler [Mon, 22 Feb 2021 11:50:29 +0000 (12:50 +0100)]
workspace: Scale down wallpaper by a fixed number of pixels
To ensure the workspace thumbnails are vertically closer to the window
picker than to the search, scale down the wallpapers by a fixed number
of pixels. Using 24 px for this means we'll take of 12 px at the top and
12 px at the bottom of the wallpaper, that's a better strategy than
always scaling it by a fixed factor since it doesn't change with the
monitor size.
Jonas Dreßler [Mon, 22 Feb 2021 11:46:42 +0000 (12:46 +0100)]
theme/search-entry: Tweak the margins a bit
Use a bit less margin at the top and add some margin at the bottom of
the search entry. This should ensure the search entry is closer to the
panel than to the workspaces and avoid associating the workspace
thumbnails with the search instead of the window picker.
Jonas Dreßler [Mon, 22 Feb 2021 11:03:51 +0000 (12:03 +0100)]
theme/dash: Tweak margins of the dash
The Dash currently has a horizontal margin and a top margin applied. The
horizontal margin isn't necessary since there already is a horizontal
padding applied, and the top margin is a bit large, since the
ControlsLayout enforces a spacing between the different containers
already, so slightly decrease the margin-top here.
Jonas Dreßler [Fri, 12 Feb 2021 15:38:47 +0000 (16:38 +0100)]
theme/overview: Use a spacing of 16px between elements
In the overview we want to make sure window previews are shown as large
as possible, so make the spacings a bit less excessive and only use a
16px spacing.
There's this little hack that we do to match the panel transition from
transparent to black with leaving the overview via swipe down. The only
problem is that, while the duration of the panel transition itself is
matches, the corners don't, and they get out of sync.
This isn't very noticeable with the swipe gesture, but it'll be much
more prominent when booting straight into the overview.
Bind the 'style' property of the panel to the corners', so that the
transition duration hack applies to all of them.
The new startup animation consists of rising the Dash from the bottom,
falling the search entry from the ceiling, and going from HIDDEN to
WINDOW_PICKER with an opacity applied.
One little trick from IconGridLayout was added to ControlsManagerLayout,
which is a promises-based wait for allocation. This is required to make
sure that the transformed position of the search entry is valid, which
is only the case right after an allocation.
This animation also ensures that the overview is shown right on startup.
For session modes that do not have an overview, continue using the same
fade + scale animation.
layout: Update workspace struts even while starting up
We want to avoid updating the input region on startup, since it incurs
in roundtrips to the X server, but not workspaces struts, since they
affect the visible clip of wallpapers in the workspace. Since next
commits will make the overview be the after-boot screen, we really
don't want the wallpaper to be clipped wrongly.
Allow updating regions while starting up, but only workspace struts.
Make sure input is not updated by accounting for 'this._startingUp'
on 'wantsInputRegion'.
This is an X11-specific routine, and building the list of input region rects
on Wayland is a waste, since it incurs in many trampolines only to throw them
in the trash.
Don't build input region rects on Wayland. By modifying the 'wantsInputRegion'
variable, it also skips actors that only update input, which is another small
optimization for Wayland.
LayoutManager doesn't update struts when there's any modal running. Turns
out, the Overview itself is a modal. That, and the fact that the Overview
will be the startup state, prevents the workarea to be updated.
Allow updating struts when there's no other modal than the Overview.
status/network: Use the same signal strength values as GNOME Settings
Be consistent and use the same wifi signal strength thresholds that are
used by Settings to ensure that the signal strengths look the same in
Settings and gnome-shell.
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/master/panels/netwo>
for the values used in Control Center.
Florian Müllner [Mon, 15 Jun 2020 18:41:45 +0000 (20:41 +0200)]
shell/app: Handle workspace from startup notifications
Launching applications on a particular workspace works through
launch contexts and startup notifications. While this is no
longer required by a launcher/WM split, in theory this allows
us to reliably identify the correct window to apply startup
properties to.
However in practice we fail more often than not: Missing support in
toolkits, differences between display protocols, D-Bus activation
and single-instance applications all provide their own pitfalls.
So instead, take advantage of the fact that launcher and WM live in
the same process, and go with the unsophisticated approach: Just
remember the last workspace that was requested when launching an
app, then move the next window that is associated with the app to
that workspace.
This will break X11 applications that set an initial workspace, but
that's legacy functionality anyway (given that there's no wayland
protocol for that functionality), and seems a price worth paying
for making launching apps on workspaces more reliable.
Carlos Garnacho [Tue, 23 Feb 2021 22:39:29 +0000 (23:39 +0100)]
appDisplay: Don't reset adjustment on ::pages-changed
Let the goToPage call afterwards to take precedence, instead
of resetting the adjustment (thus the view) on the side.
This resulted in strange state when the last page contains
a single icon, and it is dragged. The last page being emptied
triggers a pages-changed signal, which half resets the view
to the first page while DnD is ongoing.
Letting goToPage do its business means we neatly clamp to the
closest page to currentPage, the last page in that case.
Carlos Garnacho [Tue, 23 Feb 2021 16:44:23 +0000 (17:44 +0100)]
appDisplay: Slide page hints along page switching
When clicking on the page hints, the hint rectangles being visible
in place and not moving together with the page is a bit too
distracting.
Since the page hints are not part of the iconGrid hierarchy and
we have just 2 general ones for prev/next page (i.e. no page
associated), do this sliding via some smoke and mirrors: We don't
slide the page hints, but a parent container for both of them, and
we also control opacity so that the container is fully transparent
mid-page. At the point it is transparent, the container can be
snapped to the other side of the page, and faded back in as it
slides together with it, so it always looks like it goes away and
comes from the right sides.
projects / gnome-shell.git / log